【レポート】AWS PrivateLink Deep Dive #reinvent #NET310

【レポート】AWS PrivateLink Deep Dive #reinvent #NET310

Clock Icon2017.12.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS re:Invent 2017のセッションNET310 - NEW LAUNCH! AWS PrivateLink Deep Diveを聴講したのでレポートします。

スピーカーはColm MacCarthaigh(Sr Principal Engineer, Amazon)、Matthew Glickman(VP of Product, Snowflake) Larry Hook(Public Cloud Services Leader, General Electric)です。

既にセッション動画がYoutubeで公開されています。

PrivateLinkは、EC2やRDSを接続出来るVPCに直接サービスを提供する仕組みです。サービスはユーザー自身の他、サードバーティーやAWSによるものが含まれます。VPCエンドポイントとしては、2年前からあるS3エンドポイントがありますが、それらとPrivateLinkが異なるのはPrivate IPの帯域があります。既存のVPCのCIDRに対応出来るし、セキュリティグループやDirect ConnectなどVPCの機能との組み合わせも可能です。

11/8にリリースしたばかりの新機能。

  • PrivateLinkによるAPIのエンドポイントとしてAmazon Kinesis Stream、EC2、ELB、EC2 Systems Manager(現AWS Systems Manager)、Service Catalogをサポート。VPC外部への接続なしでこれらのAPIにアクセス可能に。
  • VPCのセキュリティグループに対応
  • IAMポリシーに対応

パブリックIPを利用しないので、セキュリティリスクを低減できる。エンドポイントはregional(リージョン単位)とzonal(アベイラビリティゾーン単位)がそれぞれ提供されるので、クライアントの要件(例えば、ローカルゾーン(EC2インスタンスと同じゾーン)のエンドポイントにアクセスさせたいなど)によって使い分けることができる。

ただ、これらの名前は長いので、ELBのDNS名と同様にCNAMEやエイリアスなどDNSで別名を付けてもよいでしょう。レイテンシを最小にするために複数ゾーンのレコードを登録し、可用性を考慮して最低2つ以上を使用します。登録するエンドポイント名はアカウント毎に異なる点に注意してください。

また、クロスリージョン構成を検討する場合は、可用性やデータの主権(データの持ち出しが現地法上で問題がないかなど)を考慮してください。

今週水曜日に発表したのがPrivateLink for Customers and Partnersです。PricvateLinkと同等の機能を誰にでもサービスを提供できるようにしたものです。サービスベンダーが他のユーザーにプライベートネットワークを介してサービスを提供でき、Marketplaceと統合され課金の仕組みも含まれます。複数のVPC、例えばマイクロサービスやチーム毎にVPCを作成している場合でもPrivateLinkはそれらを接続するために利用できます。

どのように動くのかの構成が以下です。PrivateLinkを他のVPCやアカウントにエクスポートするためにNLBを介すため、インスタンスやコンテナのトラフィックは低い中継コスト、TCPセッションのハンドリング、ヘルスチェック、メトリクス、AutoScalingなどNLBの機能が活用できます。

利用者側でのエンドポイント利用のライフサイクルを示したものが以下です。

それぞれAmazon SNSの通知フレームワークと連動し、承認フローはVPCピアリング接続に似ています。利用者のアカウントから申請し、プロバイダのアカウントに通知が来てそれを承認する流れです。AWS Lambdaを組み合わせることで、フローを自動化することもできます。

Tips : カスタムDNS

Tipsとしては、エンドポイントを憶えやすい名前にするために、ELBのDNS名と同様にCNAMEやRouet 53のエイリアスレコードで別名を付けるのがオススメです。必要に応じてワイルドカードDNSやSSL証明書を組み合わせても良いでしょう。

Tips : マルチテナント

サービスプロバイダの設計としては、シングルテナントにするかマルチテナントにするかを検討します。

シングルテナントモードは、クライアント毎にPrivateLink NLBを用意するパターンです。サービスのアプリケーションがマルチテナントに対応しない場合もこちらを選ぶことになるでしょう。

マルチテナントモードは複数のクライアントにPrivateLinkを構成しつつ、共通のバックエンドでAPIを提供するパターンです。KinesisやEFSと同様ですね。アプリケーションレベルで確実に動作させるためにやらなければならないことはたくさんありますが、ネットワークレベルで必要な事柄としては、どのユーザーからのアクセスなのか識別するための仕組みが必要です。以下の3つが考えられます。

  1. 従来のアカウント名/パスワード/セキュリティトークンによる認証をアプリケーションレベルで実装する
  2. NLBを分けて異なるターゲットポートに転送する
  3. Proxy Protocol V2を有効にする

Proxy Protocol V2の一般的な実装に合わせて拡張したもので、TCPトラフィックの先頭に以下のフォーマットを追加します。

これにより、トラフィックがどのVPCエンドポイントIDから来たものか、判別することができます。デメリットとして、Webサーバーやアプリケーションサーバーでこれらのフォーマットに合わせたパッチ対応が必要です。

事例 : Snowflake, GE

セッション後半では、クラウドデータウェアハウスのSaaSサービスを提供するSnowflakeとGEの事例が披露されました。

SnowFlakeでは、従来インターネット経由だった顧客のVPCとのトラフィックを...

PrivateLinkにしたこと

さらにそれをDirect Connectと組み合わせて顧客のオンプレミスネットワークからプライベート接続する構成が紹介されました。

所感

PrivateLinkを利用したサービス提供の実践的なアーキテクチャについて詳しく聞くことができる、貴重な機会でした。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.